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The IEEE 802/IETF Relationship 
Abstract 


This document describes the standardization cooperation between 
Project 802 of the Institute of Electrical and Electronics Engineers 
(IEEE) and the Internet Engineering Task Force (IETF). This document 
obsoletes RFC 4441. 


Note: This document was collaboratively developed by authors from 
both the IEEE 802 and IETF leadership and was reviewed and approved 
by the IEEE 802 Executive Committee prior to publication. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Architecture Board (IAB) 
and represents information that the IAB has deemed valuable to 
provide for permanent record. It represents the consensus of the 
Internet Architecture Board (IAB). Documents approved for 
publication by the IAB are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http: //www.rfc-editor.org/info/rfc7241. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


This document contains a set of principles and guidelines that serve 
as the basis for coordination between Project 802 of the Institute of 
Electrical and Electronics Engineers (IEEE 802) and the Internet 
Engineering Task Force (IETF), a program under the Internet Society 
(ISOC) organizational umbrella [BCP101]. The objective is to 
encourage timely development of technical specifications that 
facilitate maximum interoperability with existing (fixed and mobile) 
Internet systems, devices, and protocols. Each organization will 
operate according to their own rules and procedures including rules 
governing IPR policy, specification elaboration, approval, and 
maintenance. 


While this document is intended to improve cooperation between the 
two organizations, it does not change any of the formal practices or 
procedures of either organization. 


1.1. Why Cooperate? 


IEEE 802 and the IETF are independent standards organizations that 
each use standards produced by the other organization and develop 
standards dependent on those produced by the other organization. 
This dependency may extend to carrying attributes in protocols that 
reflect technologies defined by the other organization. 


The dependencies between IEEE 802 and IETF standards are a motivation 
for cooperation between the organizations. However, since the 
benefits of cooperation come at the cost of coordination overhead, 
the benefits of coordination must outweigh the cost. 


The IETF benefits from coordination by obtaining improved access to 
IEEE 802 expertise in the widely deployed and widely used IEEE 802 
Local Area Network architecture [ARCH802]. 


IEEE 802 benefits from coordination by obtaining improved access to 
IETF expertise on IP datagram encapsulation, routing, transport, and 
security, as well as specific applications of interest to IEEE 802. 


2. Organization, Participation, and Membership 
IEEE 802 and IETF are similar in some ways but different in others. 


When working on projects of interest to both organizations, it is 
important to understand the similarities and differences. 


Dawkins, et al. Informational [Page 4] 


RFC 7241 IEEE 802/IETF Relationship July 2014 


2.1. IEEE 802 


The IEEE Standards Association (IEEE-SA) is the standards-setting 
body of the IEEE. The IEEE-SA Standards Board oversees the IEEE 
standards development process. 


The IEEE-SA Standards Board supervises what IEEE calls "sponsors" -- 
IEEE entities that develop standards. The IEEE 802 LAN/MAN Standards 
Committee is a sponsor that develops and maintains networking 
standards and recommended practices for local, metropolitan, and 
other area networks, using an open and accredited process, while 
advocating for them on a global basis. Areas of standardization work 
include Ethernet, Bridging and Virtual Bridged LANs, Wireless LAN 
(Local Area Network), Wireless PAN (Personal Area Network), Wireless 
MAN (Metropolitan Area Network), Wireless Coexistence, Media 
Independent Handover Services, and Wireless RAN (Regional Access 
Network). Within IEEE 802, a Working Group provides the focus for 
each of these areas. 


In IEEE 802, work is done in Working Groups operating under an 
Executive Committee. Each Working Group is led by a Working Group 
Chair. Most Working Groups have one or more Task Groups. A Task 
Group is responsible for a project or group of projects. 


The Executive Committee is comprised of the Executive Committee 
Chair, Executive Committee Officers (e.g., Vice-Chairs, Secretaries, 
Treasurer), and Working Group Chairs. 


A good place to learn more is the IEEE 802 Home Page, at 
<http://www.ieee802.org/>. An IEEE 802 Orientation for new 
participants that gives an overview of IEEE 802 process is available 
from the home page. 


The IEEE 802 Executive Committee and all Working Groups meet three 
times per year at plenary sessions. Plenary sessions are held in 
March, July, and November. Most Working Groups hold interim 
meetings, usually in January, May, and September. The meeting 
schedule can be found at <http://www.ieee802.org/meeting/index.html>. 


A Study Group is a group formed to consider starting a new project 
and, if new work is found to be suitable, to develop an IEEE Project 
Authorization Request (PAR), similar in purpose to an IETF Working 
Group charter. A Study Group may operate under a Working Group or 
under the Executive Committee depending on whether the new work under 
consideration falls within the scope of an existing Working Group. 
Study Groups are expected to exist for a limited time, usually for 
one or two plenary cycles, and must be authorized to continue at each 
plenary if they have not completed their work. 
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Participation in IEEE 802 Working Groups is at the level of 
individuals -- participants are human beings and not companies. 

While participation is open, individuals are required to declare 
their affiliation (i.e., any individual or entity that financially or 
materially supports the individual’s participation in IEEE 802). 


Working Groups maintain membership rosters, with voting membership 
attained on the basis of in-person meeting attendance. Retention of 
voting membership generally requires continued attendance and 
responsiveness to letter ballots. Voting membership allows one to 
vote on motions and on Working Group Ballots of drafts. All drafts 
are also balloted by a Sponsor ballot pool before approval as 
standards. Joining a Sponsor ballot pool does not require 
participation in meetings. It is not necessary to be eligible to 
vote in order to comment on drafts, and the Working Group is required 
to consider and respond to all comments submitted during Working 
Group and Sponsor ballots. 


To foster ongoing communication between IEEE 802 and IETF, it is 
important to identify and establish contact points within each 
organization. IEEE 802 contact points may include: 


IEEE 802 Working Group Chair: An IEEE 802 Working Group chair is an 
individual who is assigned to lead the work of IEEE 802 ina 
particular area. IEEE 802 Working Group chairs are elected by 
the Working Group and confirmed by the Executive Committee for 
a two-year term. The Working Group Chair provides a stable 
contact point for cooperation between the two organizations for 
a given topic. 


IEEE 802 Task Group (or Task Force) Chair: An IEEE 802 Task Group 
chair is an individual who is assigned to lead the work on a 
specific project or group of projects within a Working Group. 
The Task Group Chair often serves for the duration of a 


project. The Task Group Chair provides a stable contact point 
for cooperation between the two organizations on a particular 
project. 


IEEE 802 Study Group Chair: An IEEE 802 Study Group Chair is an 
individual assigned to lead consideration of new work and 
development of an IEEE 802 Project Authorization Request (PAR). 
The Study Group chair provides a stable contact point for 
cooperation between the two organizations on a study group 
topic. 
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IEEE 802 Liaisons: It may be beneficial to establish liaisons as 
additional contact points for specific topics of mutual 
interest. These contact points should be established early in 
the work effort. The IEEE 802 and IETF projects may select the 
same individual as their contact point, but this is not 
required, so that two individuals each serve as contact points 
for one project participating in the liaison relationship. 


Informal Contact points: Other informal contacts can provide useful 
cooperation points. These include Project Editors who are 
responsible for editing the drafts and work with the Task Group 
Chairs to lead tracking and resolution of issues. Joint 
members who are active in both the IEEE 802 and IETF projects 
in an area can also aid in cooperation. 


Dido, IETF 
The IETF Standards Process is defined in [BCP9]. [BCP11] is a 
helpful description of organizations involved in the IETF standards 
process. It can still be useful as an overview, although details 


have changed since 1996. 


In the IETF, work is done in Working Groups (WGs) and is mostly 
carried out through open, public mailing lists rather than face-to- 
face meetings. The IETF Working Group process is defined in [BCP25]. 


WGs are organized into areas, and each area is managed by one or more 
Area Directors. Collectively, the Area Directors constitute the 
Internet Engineering Steering Group (IESG) [RFC3710]. 


To foster ongoing communication between IEEE 802 and IETF, it is 
important to identify and establish contact points within each 
organization. IETF contact points may include Area Directors, 
Working Group chairs, and other points of contact who can help 
communicate between IEEE 802 and IETF Working Groups. 


The Internet Architecture Board (IAB) charter [BCP39] assigns the IAB 
several responsibilities relevant to this document: 


IESG Appointment Confirmation [BCP10] 

Architectural Oversight 

Standards Process Oversight and Appeal 

Appointment of the RFC Series Editor [RFC6635] and Independent 

Submission Editor [RFC6548] 

5. Appointment of the Internet Assigned Number Authority (IANA) 
operator [RFC6220] 

6. Oversight of External Liaisons for the IETF [BCP102] 


Ss UN ER 
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IESG and IAB members are selected using the NomCom process defined in 
[BCP10]. Working Group chairs serve at the pleasure of their Area 
Directors, as described in [BCP25]. 


The IETF is designed to be a "bottom-up" protocol engineering 
organization -- the leadership steers and manages but does not direct 
work in a top-down way. Technical agreements with "the IETF" are 
based on the consensus of Working Group participants, rather than 
negotiated with IETF leadership. 


IETF meets in plenary sessions three times per year. Some Working 
Groups schedule additional interim meetings, which may be either 
face-to-face or "virtual". Information about IETF meetings is 
available at <http://www.ietf.org/meeting/upcoming.html>. 

Information about IETF Working Group interim meetings is available on 
<http://www.ietf.org/meeting/interim-meetings.html>. 


The preferred way to develop specifications is to do work on mailing 
lists, reserving face-to-face sessions for topics that have not been 
resolved through previous mailing list discussion. 


Participation in the IETF is open to anyone (technically, anyone with 
access to email sufficient to allow subscription to one or more IETF 
mailing lists). All IETF participants act as individuals. There is 
no concept of "IETF membership". 


A good place to learn more is the IETF Home Page, at 
<http://www.ietf.org/>, and especially the "About the IETF" page at 
<http://www.ietf.org/about>, selectable from the IETF Home Page. 


The "Tao of the IETF" is also very helpful, especially for IEEE 802 
participants who will also be participating in IETF Working Groups 
and attending IETF meetings. It is available at 
<http://www.ietf.org/tao.html>. 


The current list of IETF Area Directors and Working Group chairs can 
be found in the IETF Working Group charters, at 
<http://datatracker.ietf.org/wg/>. 


2.3. Structural Differences 
IEEE 802 and IETF have similar structures, but the terms they use are 
different, and even conflicting. For example, both IEEE 802 and IETF 


use the term "Working Group", but this means very different things in 
the two organizations. 


Dawkins, et al. Informational [Page 8] 


RFC 7241 IEEE 802/IETF Relationship July 2014 


Thumbnail comparison between IETF and IEEE 802 entities 


IETF Area is similar to IEEE 802 Working Group 
IETF Working Group is similar to IEEE 802 Task Group 
IETF BOF is similar to IEEE 802 Study Group 


Both IEEE 802 Working Groups and IETF Areas are large, long-lived, 
and relatively broadly scoped, containing more narrowly chartered 
entities (IEEE 802 Task Groups and IETF Working Groups), which tend 
to be short-lived and narrowly chartered. IEEE 802 uses Study Groups 
to develop proposals for new work, and these are analogous to IETF 


Birds of a Feather ("BOF") sessions. 


Several IETF Areas also have one or more directorates to support the 
work of the Area Directors. Area Directors often ask directorate 
members to review documents or provide input on technical questions. 
These directorates are often a source of expertise on specific 
topics. The list of Area Directorates is at 
<http://www.ietf.org/iesg/directorate.html>. IEEE 802 does not have 
a corresponding organizational entity. 


2.4. Cultural Differences 


IEEE 802 and IETF have cultures that are similar but not identical. 
Some of the differences include: 


Consensus and Rough Consensus: Both organizations make decisions 
based on consensus, but in the IETF, "consensus" can mean 
"rough consensus, as determined by Working Group chairs". In 
practice, this means that a large part of the community being 
asked needs to agree. Not everyone has to agree, but if 
someone disagrees, they need to convince other people of their 
point of view. If they're not able to do that, they'll be "in 
the rough" when "rough consensus" is declared. Although IEEE 
Working Groups ultimately rely on voting for decision-making, 
they vary widely in their use of consensus versus voting in the 
course of a meeting and in their attention to Robert’s Rules 
[RONR] . 


Running Code: David Clark coined the phrase "We reject kings, 
presidents and voting. We believe in rough consensus and 
running code" in 1992, to explain IETF culture. Although 
that’s not always true today, the existence of "running code" 
as a proof of feasibility for a proposal often carries weight 
during technical discussions. IEEE 802 considers both 
technical and economic feasibility when deciding whether to 
approve new work, as noted in Section 4.1.7. 
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Decision-making: IEEE 802 Working Groups vary in their reliance upon 
voting versus consensus, and in the breadth of coverage of an 
individual motion, but ultimately, all rely upon a 75 percent 
vote to decide technical issues, and a 50 percent +1 vote to 
decide other issues. IETF Working Groups do not use voting. 
Working Group chairs may ask for a "show of hands" or "take a 
hum" to judge backing for a proposal and identify technical 
concerns and objections, but this is not considered "voting". 
IETF consensus and humming is discussed further in [RFC7282]. 


Balance between mailing lists and meetings: Both organizations make 
use of mailing lists. IETF Working Groups rely heavily on 
mailing lists, where work is done, in addition to formal 
meetings. The IETF requires all Working Group decisions to be 
made (or, often in practice, confirmed) on mailing lists -- 
final decisions aren't made in meetings. IEEE 802 Working 
Groups typically meet face-to-face about twice as often as IETF 
Working Groups (three IEEE 802 plenaries plus three IETF 802 
interim meetings each year, compared to three IETF plenaries 
per year), and teleconferences are more common in IEEE 802 than 
in most IETF Working Groups. Most major decisions in IEEE 802 
are made during plenary or interim meetings, except for 
procedural decisions. Attendance at meetings is critical to 
influencing decisions and to maintaining membership voting 


rights. 

Interim meetings: Both organizations use interim meetings (between 
plenary meetings). IETF Working Groups schedule interim 
meetings on an as-needed basis. IETF interim meetings may be 


face-to-face or virtual. Most IEEE 802 WGs hold regularly 
interim meetings three times a year in the middle of the 


interval between two plenary meetings. The schedules and 
locations of these meetings are typically known many months in 
advance. IEEE 802 interim meetings are face-to-face only. In 


= 


addition to regularly scheduled IEEE 802 interim meetings, 
teleconference and ad hoc meetings are held on an as-needed 
basis. 


Remote participation: Because the IETF doesn’t make decisions at 
face-to-face meetings, attendance is not absolutely necessary, 
and some significant contributors do not attend most face-to- 
face IETF meetings. However, finding people interested ina 
proposal for new work, or soliciting backing for ideas, is 
often more easily accomplished face-to-face, such as ina 
hallway or bar. Significant contributors to IEEE 802 almost 
always attend face-to-face meetings; participation in IEEE 802 
meetings is a condition for WG membership. 
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Lifetime of Standards: IEEE 802 periodically reviews existing 
standards. IETF Standards Track documents may be updated or 
obsoleted by newer Standards Track documents, but there is no 
formal periodic review for existing Standards Track documents. 
The status of specific IETF standards is available through the 
IETF "Datatracker" [DATATRACKER]. Because these status changes 
happen independently, standards from each organization may 
refer to documents that are no longer standards in the other 
organization. 


Overlapping terminology: As two independent standards development 
organizations, IEEE 802 and IETF have developed vocabularies 
that overlap. For instance, IEEE 802 "ballots" at several 
levels of the organization during document approval, while IETF 
documents are only "balloted" during IESG review. The IESG 
uses "ballots" to indicate that all technical concerns have 
been addressed, not to indicate that the IESG agrees with a 


document. The intention is to "discuss" technical issues with 
a document, and "no" is not one of the choices on an IESG 
ballot. 


2.5. Mailing Lists 


All IETF Working Groups and all IEEE 802 Working Groups have 
associated mailing lists. Most IEEE 802 Task Groups also have 
mailing lists, but in some cases (e.g., the IEEE 802.1 Working 
Group), the Working Group mailing list is used for any Task Group 
matters. 


In the IETF, the mailing list is the primary vehicle for discussion 
and decision-making. It is recommended that IEEE 802 experts 
interested in particular IETF Working Group topics subscribe to and 
participate in these lists. IETF WG mailing lists are open to all 
subscribers. The IETF Working Group mailing list subscription and 
archive information are noted in each Working Group’s charter page. 


In IEEE 802, mailing lists are typically used for meeting logistics, 
ballot announcements, reports, and some technical discussion. Most 
decision-making is at meetings, but in cases where a decision is 
needed between meetings, it may be done over the mailing list. Most 
technical discussion occurs at meetings and by generating comments on 
drafts that are compiled with responses in comment resolution 
documents. 
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Most IEEE 802 mailing lists are open to all subscribers. For the few 
IEEE 802 mailing lists that are not open, please see the Working 
Group chair to arrange for access to the mailing list. 


Some IEEE 802 participants refer to mailing lists as "reflectors". 
3. Document Access and Cross-Referencing 


During the course of IEEE 802 and IETF cooperation, it is important 
to share internal documents among the technical Working Groups. In 
addition, drafts of IEEE 802 standards, Internet-Drafts, and RFCs may 
also be distributed. 


3.1. Access to IETF Documents 


IETF Internet-Drafts may be located using the IETF Datatracker 
interface (see [DATATRACKER]) or via the IETF tools site at 
<http://tools.ietf.org>. RFCs may be found at either of the above 
sites, or via the RFC Editor web site at <http://www.rfc-editor.org>. 


3.2. Access to IEEE 802 Standards 


IEEE 802 standards, once approved, are published and made available 
for sale. They can be purchased from the IEEE Standards Store, at 
<http://www.techstreet.com/IEEEgate.html>. They are also available 
from other outlets, including the IEEE Xplore digital library, at 
<http://ieeexplore.ieee.org>. 


The Get IEEE 802 program, at <http://standards.ieee.org/about/get>, 
grants public access to download individual IEEE 802 standards at no 
charge (although registration is required). IEEE 802 standards are 
added to the Get IEEE 802 program six months after publication. This 
program is approved year by year, but has been in place for several 
years. 


3.3. Access to IEEE 802 Working Group Drafts 


The IEEE owns the copyright to drafts of standards developed within 
IEEE 802 standardization projects. The IEEE-SA grants permission for 
an IEEE 802 draft to be distributed without charge to the 
participants for that IEEE 802 standards development project. 
Typically, access is provided over the Internet under password 
protection, with the password provided to members of the 
participating WG. Requests to the relevant WG Chair for access to a 
draft for purposes of participation in the project are typically 
granted. 
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An alternative access mechanism which may more easily enable document 
access for IETF WGs cooperating with IEEE 802 was established by a 
liaison statement sent to the IETF in July 2004 by Paul Nikolich, 
Chair of IEEE 802 (available at <https://datatracker.ietf.org/ 
documents/LIAISON/file41.pdf>), describing the process by which IETF 
WGs can obtain access to IEEE 802 work in progress. IEEE 802 WG 
Chairs have the authority to grant membership in their WGs and can 
use this authority to grant membership to an IETF WG chair upon 
request. The IETF WG chair will be provided with access to the 
username/password for the IEEE 802 WG archives and is permitted to 
share that information with participants in the IETF WG. Since it is 
possible to participate in IETF without attending meetings, or even 
joining a mailing list, IETF WG chairs will provide the information 
to anyone who requests it. However, since IEEE 802 work in progress 
is copyrighted, copyright restrictions prohibit incorporating 
material into IETF documents or postings. 


In addition to allowing IETF participants to access documentation 
resources within IEEE 802, IEEE 802 can also make selected IEEE 802 
documents at any stage of development available to the IETF by 
attaching them to a formal liaison statement. Although a 
communication can point to a URL where a non-ASCII document can be 
downloaded, sending attachments in proprietary formats to an IETF 
mailing list is discouraged. 


3.3.1. IEEE 802 Documentation System 


Each IEEE 802 standardization project is assigned to a Working Group 
(WG) for development. In IEEE 802, the working methods of the WGs 
vary in their details. The documentation system is one area in which 
WG operations differ, based on varying needs and traditions. In some 
cases, the WGs assign the core development to a subgroup (typically 
known as a Task Group or Task Force), and the documentation 
procedures may vary among the subgroups as well. Prior to project 
authorization, or on topics not directly related to development of a 
standard, the WG may consider and develop documents itself or using 
other subgroups (standing committees, ad hocs, etc.). 


IEEE 802 also supports Technical Advisory Groups (TAGs) that conduct 
business and develop documents, although not standards. References 
here to WGs apply to TAGs as well. 

3.3.2. Access to Internal IEEE 802 Working Group Documents 


Generally, the archives of minutes and contributions to IEEE 802 
groups are publicly and freely available. 
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Many IEEE 802 groups use a documentation system provided by IEEE and 
known as "Mentor". The list of these groups is available at the IEEE 
802 Mentor Home Page: <https://mentor.ieee.org/802>. Mentor provides 
the following features: 


1. The documentation system is structured and ordered, with 
documentation tags and unique numbering and versioning. 


2. Online documentation is available. 


3. Limited search functionality is provided, and publicly available 
search engines index the data. 


4. The ability to submit documents to Mentor is limited but is 
generally available to any interested party. An IEEE web account 
is required but can be easily and freely established using the 
IEEE Account Request page, at 
<http://www.ieee.org/go/create_web_account>. If submission is 
protected, the privilege can be requested via the Mentor system 
(using the "Join group" link on each WG Mentor page) and would 
typically be granted by the WG documentation manager in a manual 
approval. 


5. Submitted documents are immediately available to the general 
public at the same instant they become available for 
consideration by the group. 


IEEE 802.1 and IEEE 802.3 do not use Mentor. 


IEEE 802.1 documents are organized in folders by year at 
<http://www.ieee802.org/1/files/public/>. The file names indicate 
the relevant project, author, date, and version. The file-naming 
conventions and upload link are at 
<http://ww.ieee802.org/1/filenaming.html>. Upload is moderated. 


TEEE 802.3 documents are accessed from the home pages of the IEEE 
802.3 subgroups (i.e., Task Force or Study Group) and are organized 
in folders by meeting date. These home pages are available from the 
IEEE 802.3 home page, at <http://www.ieee802.org/3/>. Files are 
uploaded by emailing to the subgroup chair. 


Dawkins, et al. Informational [Page 14] 


RFC 7241 IEEE 802/IETF Relationship July 2014 


3.3.3. Contributions to IEEE 802 Working Groups 


In general, development of standards in IEEE 802 is contribution 
driven. In many cases, a WG or subgroup will issue a call for 
contributions with a specific technical solicitation, including 
deadlines and submission instructions. Some groups maintain specific 
submission procedures and specify a contribution cover sheet to 
clarify the status of the contribution. 


Content for drafts of standards is submitted to WGs by individual 
participants or groups of participants. Content toward other group 
documents (such as, for example, external communication statements or 
foundation documents underlying a draft of a standard) might also be 
contribution driven. At some point, the group assembles contributed 
material to develop group documents, and revision takes place within 
group meetings or by assignment to Editors. For the most part, the 
contributions toward discussion as well as the group documents 
(including minutes and other reports) are openly available to the 
public. 


3.4. Cross-Referencing 


IETF and IEEE 802 each recognize the standards defined by the other 
organization. Standards produced by each organization can be used as 
references in standards produced by the other organization. 


IETF specifications may reference IEEE 802 work in progress, but 
these references should be labeled "Work in Progress". If the 
references are normative, this will block publication of the 
referring specification until the reference is available in a stable 
form. 


IEEE 802 standards may normatively reference non-expired Internet- 
Drafts, but IEEE 802 prefers that this be avoided if at all possible. 


Informative references in IEEE 802 standards are placed in a 
bibliography, so they may point to either approved IETF standards or 
IETF Internet-Drafts, if necessary. 


When an IEEE 802 standard is revised, it normally retains the same 
number and the date is updated. Therefore, IEEE 802 standards are 
dated with the year of approval, e.g., IEEE Std 802.10(TM)-2011. 
There are two ways of referencing IEEE 802 standards: undated and 
dated references. IEEE 802 practice allows undated reference to be 
used when referencing a whole standard. An undated reference 
indicates that the most recent version of the standard should be 
used. A dated reference refers to a specific revision of an IEEE 802 
standard. Since clauses, subclauses, tables, figures, etc., may be 
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renumbered when a standard is revised, a dated reference should be 
used when citing specific items in a standard. 


IETF standards may be cited by RFC number, which would also be a 
dated reference. If an undated reference to an IETF Internet 
Standard is desired, a number is also assigned in the "STD" series 
[BCP9], and these references refer to the most recent version of an 
IETF Internet Standard. 


4. Guidance on Cooperation 


This section describes how existing processes within the IETF and 
IEEE 802 may be used to enable cooperation between the organizations. 


Historically, much of the work of coordination has fallen on 
individuals attending meetings of both organizations. However, as 
noted in "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 
WG" [RFC4663], downward pressure on travel budgets has made it 
increasingly difficult for participants to attend face-to-face 
meetings in both organizations. That pressure has continued in the 
intervening years. As a result, the coordination mechanisms 
described in this section typically do not require meeting 
attendance. 


4.1. Exchange of Information about Work Items 


The following sections outline a process that can be used to enable 
each organization to stay informed about the other’s active and 
proposed work items. 


Early identification of topics of mutual interest allows the two 
organizations to cooperate in a productive way and helps each 
organization avoid developing specifications that overlap or conflict 
with specifications developed in the other organization. Where 
individuals notice a potential conflict or need for coordination, the 
issue should be brought to the attention of the relevant Working 
Group chairs and/or Area Directors. 


4.1.1. How IEEE 802 Is Informed about Active IETF Work Items 


The responsibility is on IEEE 802 Working Groups to review current 
IETF Working Groups to determine if there are any topics of mutual 
interest. Working Group charters and active Internet-Drafts can be 
found in the IETF Datatracker [DATATRACKER]. If an IEEE 802 Working 
Group identifies a common area of work, the IEEE 802 Working Group 
leadership should contact both the IETF Working Group chair and the 
Area Director(s) responsible. This may be accompanied by a formal 
liaison statement (see Section 5.2). 
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4.1.2. How IETF Is Informed about Active IEEE 802 Work Items 


It is the responsibility of IETF Working Groups to periodically 
review the IEEE 802 web site to determine if there is work in 
progress of mutual interest. 


IEEE 802 Working Group status reports are published at the beginning 
and end of each plenary at <http://ieee802.org/minutes>. Each 
Working Group includes a list of their active projects and the 
status. 


The charter of an IEEE 802 project is defined in an approved Project 
Authorization Request (PAR). PARs are accessible in IEEE Standards 
myProject, at <https://development.standards.ieee.org>. Access 
requires an IEEE web account, which is free and has no membership 
requirement. 


In myProject, a search on "View Active PARs" for 802 will bring up a 
list of all active IEEE 802 PARs. 


If an IETF working group identifies a common area of work or a need 
for cooperation, the Working Group leadership should contact the IEEE 
802 Working Group Chair and Task Group Chair. This may be 
accompanied by a formal liaison statement (see Section 5.2). 


4.1.3. Overview of Notifications of New Work Proposals 


These principles describe the notification process used by both 
organizations: 


1. For both organizations, the technical group making a proposal for 
new work that may conflict with, overlap with, or be dependent on 
the other organization is responsible for informing the top-level 
coordination body in the other organization that cooperation may 
be required. 


2. For both organizations, the top-level coordination body receiving 
that notification is responsible for determining whether 
cooperation is, in fact, required, and informing the specific 
groups within the organization who may be affected by the 
proposal for new work. 


These direct notifications will be the most common way that each 

organization is informed about proposals for new work in the other 
organization. Several other ways of identifying proposed new work 
are described in the following sections. These additional ways act 
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as "belt and suspenders" to reduce the chances that proposals for new 
work in one organization escape notice in the other organization when 
cooperation will be required. 


4.1.4. The New-Work Mailing List 


Several standards development organizations (SDOs), including IETF 
and IEEE 802, have agreed to use a mailing list for the distribution 
of information about proposals for new work items among these SDOs. 


Rather than having individual IEEE 802 participants subscribe 
directly to New-Work, a single IEEE 802 mailing list is subscribed. 
Leadership of the IEEE 802 Working Groups may subscribe to this 
"second-level" IEEE 802 mailing list, which is maintained by the 
Executive Committee (EC). 


This mailing list is limited to representatives of SDOs proposing new 
work that may require cooperation with the IETF. Subscription 
requests may be sent to the IAB Executive Director. 


4.1.5. How IEEE 802 Is Informed about Proposed New IETF Work Items 


Many proposals for new IETF work items can be identified in proposed 
Birds of a Feather (BOF) sessions, as well as draft charters for 
Working Groups. The IETF forwards all such draft charters for new 
and revised Working Groups and BOF session announcements to the IETF 
New-Work mailing list. 


4.1.6. How IEEE 802 Comments on Proposed New IETF Work Items 


Each IEEE 802 Working Group Chair, or designated representative, may 
provide comments on these charters by responding to the IESG mailing 
list at iesg@ietf.org clearly indicating their IEEE 802 position and 
the nature of their concern. 


It should be noted that the IETF turnaround time for new Working 
Group charters can be as short as two weeks, although the call-for- 
comment period on work items that may require cooperation with IEEE 
802 can be extended to allow more time for discussion within IEEE 
802. This places a burden on both organizations to proactively 
communicate and avoid "late surprises" to either organization. 


Although an IEEE 802 Working Group may not be able to develop a 
formal consensus response unless the notification arrives during that 
Working Group’s meeting, the IEEE 802 Working Group chair can 
informally let the IETF know that IEEE 802 may have concerns about a 
proposed work item. The IETF will consider any informal comments 
received without waiting for a formal liaison statement. 
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4.1.7. How IETF Is Informed about Proposed New IEEE 802 Work Items 


An IEEE 802 project is initiated by approval of a Project 
Authorization Request (PAR), which includes a description of the 
scope of the work. Any IEEE 802 PARs that introduce new 
functionality are required to be available for review no less than 30 
days prior to the Monday of the IEEE 802 plenary session where they 
will be considered. 


IEEE 802 considers "Five Criteria" when deciding whether to approve 
new work: Broad Market Potential, Compatibility, Distinct Identity, 
Technical Feasibility, and Economic Feasibility. The criteria are 
defined in the IEEE 802 LAN/MAN Standards Committee (LMSC) Operations 
Manual. The PARs are accompanied by responses on the "Five 
Criteria". 


IEEE 802 posts proposed PARs to the New-Work mailing list, prior to 
the IEEE 802 meetings where the PARs will be discussed. The IETF 
coordination body will notify technical groups about PARs of 
interest. 


4.1.8. How IETF Comments on Proposed New IEEE 802 Work Items 


Any comments on proposed PARs should be submitted to the Working 
Group Chair and copied to the Executive Committee chair by email not 
later than 5:00 PM Tuesday of the plenary session (in the time zone 
where the plenary is located). 


4.1.9. Other Mechanisms for Coordination 


From time to time, IEEE 802 and IETF may agree to use additional 
mechanisms for coordination between the two groups. The details of 
these mechanisms may vary over time, but the overarching goal is to 
communicate effectively as needed. 


As examples of such mechanisms, at the time this document was 
written, the two organizations are holding periodic conference calls 
between representatives of the IETF and IEEE 802 leadership teams, 
and are maintaining a "living list" of shared interests between the 
two organizations, along with the status of these interests and any 
related action items. At the time this document was written, the 
"living list" included about 20 topics being actively discussed, with 
more expected. These conference calls help the two organizations 
coordinate more effectively by allowing higher-bandwidth discussions 
than formal liaison statements would allow and by permitting more 
timely interactions than waiting for face-to-face meetings. 
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Minutes for these conference calls, and the "living lists" discussed 
on each call, are available at <http://www.iab.org/activities/ 
joint-activities/iab-ieee-coordination/>. 


4.2. Document Review and Approval 


During the course of IEEE 802 and IETF cooperation, it is important 
for technical experts to review documents of mutual interest and, 
when appropriate, to provide review comments to the approving body as 
the document moves through the approval process. 


4.2.1. IEEE 802 Draft Review and Balloting Processes 


IEEE 802 drafts are reviewed and balloted at multiple stages of the 
draft. Any ballot comments received from non-voters before the close 
of the ballot are required to be considered in the comment resolution 
process. The Editors, Task Group Chairs, or Working Group Chairs 
responsible for the project will facilitate the entering of comments 
from non-voters. 


IEEE 802 draft reviews and ballots sometimes produce a large volume 
of comments. In order to handle them efficiently, spreadsheets or a 
comment database tool are used. It is highly recommended that 
balloters and others submitting comments do so with a file that can 
be imported into these tools. A file with the correct format is 
normally referenced in the ballot announcement or can be obtained 
from the Editor, Task Group Chair, or Working Group Chair responsible 
for the project. Comments on a draft should be copied to the Editor, 
Task Group Chair, and Working Group Chair. 


4.2.1.1. Task Group Review 


During draft development, informal task group reviews (task group 
ballots) are conducted. Though these are called "ballots" by some 
Working Groups, the focus is on collecting and resolving comments on 
the draft rather than on trying to achieve a specific voting result. 


4.2.1.2. Working Group Ballot 


Once the draft is substantially complete, Working Group ballots are 
conducted. Working Group voting members are entitled and required to 
vote in Working Group ballots. Any "disapprove" votes are required 
to be accompanied by comments that indicate what the objection is and 


a proposed resolution. "Approve" votes may also be accompanied by 
comments. The comments submitted with a "disapprove" vote may be 

marked to indicate which comments need to "be satisfied" to change 
the vote. 
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Initial Working Group ballots are at least 30 days. Recirculation 
ballots to review draft changes and comment resolutions are open at 
least 10 days. 


In order to submit a WG ballot, contact the WG Chair for the 
submission tool currently in use, as the tools may change over time. 


4.2.1.3. Sponsor Ballot 


When a draft has successfully completed Working Group ballot, it 
proceeds to Sponsor ballot. One may participate in IEEE 802 Sponsor 
ballots with an individual membership in the IEEE Standards 
Association (IEEE-SA) or by paying a per-ballot fee. Participants 
are also required to state their affiliation and the category of 
their relationship to the scope of the standards activity (e.g., 
producer, user, general interest). 


Information about IEEE-SA membership can be found at 
<http://standards.ieee.org/membership/>. 


Sponsor ballot is a public review. An invitation is sent to any 
parties known to be interested in the subject matter of the ballot. 
One Can indicate interest in IEEE myProject 

(<https://development .standards.ieee.org>). An IEEE web account is 
freely available and is required for login. To select interest 
areas, go to the Projects tab and select "Manage Activity Profile" 
and check any areas of interest. IEEE 802 projects are under 
Computer Society; LAN/MAN Standards Committee. 


The Sponsor ballot pool is formed from those that accept the 
invitation during the invitation period. 


As with other ballot levels, the IETF participants who want to 
comment on Sponsor ballots need not be members in the Sponsor ballot 
pool. The Editors, Task Group Chairs, or Working Group Chairs 
responsible for the project will facilitate the entering of comments 
from IETF participants who are not members in the Sponsor ballot 
pool. 


Any "disapprove" votes are required to be accompanied by comments 
that indicate what the objection is, along with a proposed 
resolution. "Approve" votes may also be accompanied by comments. 
The comments submitted with a "disapprove" vote may be marked to 
indicate which comments need to "be satisfied" for the commenter to 
change the vote from "disapprove". 
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Initial Sponsor ballots are open for at least 30 days. Recirculation 
ballots to review draft changes and proposed comment resolutions are 
open at least 10 days. 


4.2.1.4. Ballot Resolution 


At each level, the relevant group (Task Group for TG ballots, Working 
Group for WG and Sponsor ballots) examines the ballot comments and 
determines their disposition. The Editor (or editorial team) may 
prepare proposed dispositions. Task Group procedures vary, but at 
the Working Group level, the Working Group must vote 75 percent to 
approve the final ballot disposition in order to advance the 
document. 


4.2.2. IETF Draft Review and Approval Processes 


The IETF Working Group Process is defined in [BCP25]. The overall 
IETF standards process is defined in [BCP9]. 


As noted in Section 2.4, IETF Working Groups do not "ballot" to 
determine Working Group consensus to forward documents to the IESG 
for approval. 


Technical contributions are welcome at any point in the IETF document 
review and approval process, but there are some points where 
contribution is more likely to be effective. 


1. When a Working Group is considering adoption of an individual 
draft. Adoption is often announced on the Working Group’s 
mailing list. 


2. When Working Group chairs issue a "Working Group Last Call" 
("WGLC") for a draft, to confirm that the Working Group has 
consensus to request publication. Although this is not a 
mandatory step in the document review and approval process for 
Internet-Drafts, most IETF Working Groups do issue WGLCs for most 
Working Group documents. WGLC would be announced on the Working 
Group’s mailing list. 


3. When the Internet Engineering Steering Group issues an "IETF Last 
Call" ("Last Call") for a draft. IETF Last Call is a formal and 
required part of the review and approval process, is addressed to 
the larger IETF community, and is often the first time the entire 
community has looked at the document. IETF Last Call is signaled 
on the IETF-Announce Mailing List, and comments and feedback are 
ordinarily directed to the IETF Discussion Mailing List. 
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In practice, earlier input is more likely to be effective input. 
IEEE 802 participants who are interested in work within the IETF 
should be monitoring that work and providing input long before 
Working Group Last Calls and IETF Last Calls, for best results. 


Some IETF Working Group charters direct the Working Group to 
communicate with relevant IEEE 802 Task Groups. 


4.3. Solicited Review Processes 


With the number of areas of cooperation between IEEE 802 and IETF 
increasing, the document review process has extended beyond the 
traditional subjects of SMI (Structure of Management Information) MIB 
modules and AAA (Authentication, Authorization, and Accounting) 
described in [RFC4441]. IESG members routinely solicit directorate 
reviews as a means to request the opinion of specialized experts on 
specific aspects of documents in IESG review (examples include 
security, "MIB Doctors", or congestion management reviews). Area 
Directors may also require solicited reviews from IEEE 802 or IEEE 
802 Working Groups when it becomes clear that the Internet-Draft has 
implications that impact some area of IEEE 802’s responsibility and 
expertise. 


IEEE 802 leadership can also solicit similar reviews, but these 
reviews are not included as part of the formal IEEE 802 process. 


5. Liaison Managers and Liaison Statements 


Both IEEE 802 and IETF work best when people participate directly in 
work of mutual interest, but that is not always possible, and 
individuals speaking as individuals may not provide effective 
communication between the two SDOs. From time to time, it may be 
appropriate for a technical body in one SDO to communicate as a body 
with a technical body in the other SDO. This section describes the 
mechanisms used to provide formal communication between the two 
organizations, should that become necessary. 


The Internet Architecture Board (IAB) is responsible for liaison 
relationship oversight for the IETF. In IEEE 802, liaison 
relationship oversight is distributed, and each organization 
appointing liaison managers is responsible for oversight of its own 
liaison relationships. 


The reader should note that the role of a liaison manager in both 
IEEE 802 and IETF is not to "speak for" the appointing organization. 
A liaison manager is most helpful in ensuring that neither 
organization is surprised by what’s happening in the other 
organization, helping to identify the right people to be talking to 
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in each organization, and making sure that formal liaison statements 
don’t "get lost" between the two organizations. The IAB’s guidance 
to liaison managers is available in [RFC4691]. IEEE 802 
organizations appointing each liaison manager also provide guidance 
to those liaison managers. There is no global guidance for all IEEE 
802 liaison managers. 


5.1. Liaison Managers 


The IAB appoints IETF liaison managers using the process described in 
[BCP102]. The current list of the IETF’s liaison relationships and 
the liaison managers responsible for each of these relationships is 
available at <http://www.ietf.org/liaison/managers.html>. 


IEEE liaison managers are selected by the organizations they 
represent, either in an election or by Working Group or Task Group 
Chair appointment. The current list of IEEE 802's liaison 
relationships and the liaison managers responsible for each of these 
relationships is available at 
<http://www.ieee802.org/liaisons.shtml>. 


5.2. Liaison Statements 


The IEEE 802 procedure for sending and receiving liaison statements 
is defined by the Procedure for Coordination with Other Standards 
Bodies in the IEEE 802 LMSC Operations Manual 
(<http://ieee802.org/devdocs.shtml>). 


The IETF process for sending and receiving liaison statements is 
defined in [BCP103]. 


6. Protocol Parameter Allocation 


Both IEEE 802 and IETF maintain registries of assigned protocol 
parameters, and some protocol parameters assigned in one organization 
are of interest to the other organization. This section describes 
the way each organization registers protocol parameters. 


6.1. IANA 


The IETF uses the Internet Assigned Numbers Authority (IANA) as a 
central authority that administers registries for most protocol 
parameter allocations. The overarching document describing this is 
[BCP26]. [BCP141] discusses use of IEEE 802-specific IANA parameters 
in IETF protocols and specifies IANA considerations for allocation of 
code points under the IANA OUI (Organizationally Unique Identifier). 
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Requests for protocol parameter allocations from IANA are subject to 
assignment policies, and these policies vary from registry to 
registry. A variety of well-known policies are described in [BCP26], 
but registries are not limited to one of the well-known choices. 


The purpose of these allocations is to manage a namespace 
appropriately, so unless a registry has a policy that allows 
something like first come, first served ("FCFS") for a namespace that 
is effectively unbounded, requests for protocol parameter allocation 
will require some level of review. "Standards Action" is at the 
other extreme (an approved Standards Track RFC is required in order 
to obtain an allocation). Some registries require that a request for 
allocation pass "Expert Review" -- review by someone knowledgeable in 
the technology domain, appointed by the IESG and given specific 
criteria to use when reviewing requests. 


6.2. IEEE Registration Authority 


The IEEE Standards Association uses the IEEE Registration Authority 
as a central authority administering registries. The IEEE 
Registration Authority Committee (IEEE RAC) provides technical 
oversight for the IEEE Registration Authority. 


The list of Registries administered by the IEEE Registration 
Authority can be found on the IEEE RAC web site, at 
<http://standards.ieee.org/develop/regauth/general.html>. 


Regarding Ethertype allocation: 

Some IETF protocol specifications make use of Ethertypes. Ethertypes 
are a fairly scarce resource so allocation has the following 
requirements. All Ethertype requests are subject to review by a 
consultant to the IEEE RA, followed by IEEE RAC confirmation. 


The IEEE RAC will not assign a new Ethertype to a new IETF protocol 
specification until the IESG has approved the protocol specification 
for publication as an RFC. In exceptional cases, the IEEE RA will 
consider "early allocation" of an Ethertype for an IETF protocol that 
is still under development when the request comes from, and has been 
vetted by, the IESG. 


Note that "playpen" Ethertypes have been assigned in IEEE 802 
[ARCH802] for use during protocol development and experimentation. 


While a fee is normally charged by the IEEE Registration Authority 
Committee (RAC) for the allocation of an Ethertype, the IEEE RAC will 
consider waiving the fee for allocations relating to an IETF 
Standards Track document, based on a request from the IESG. 
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6.3. IEEE 802 Registration at the Working Group Level 


July 2014 


Each IEEE 802 Working Group has a registry of identifier values and a 
mechanism to allocate identifier values in its standards and approved 
amendments. This includes items such as Object Identifiers for 
managed objects and assignment for protocols defined by that Working 
Group, such as OpCodes. Contact the IEEE 802 Working Group Chair for 


the details of a given Working Group registry. 


6.4. Joint-Use Registries 


Because some registries are "joint-use" between IEEE 802 and IETF, it 
is necessary for each organization to review usage of registries 
maintained by the other organization as part of the review and 


approval process for standards. 


If an IEEE 802 document refers to IANA registries, those references 
should be checked prior to Sponsor balloting. If an IETF document 
refers to IEEE 802 registries, those references should be checked as 


part of IANA Review during IETF Last Call. 


7. Security Considerations 


This document describes cooperation procedures and has no direct 


Internet security implications. 
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Appendix A. Current Examples of IEEE 802 and IETF Cooperation 


A. 


A. 


1. MIB Review 


Historically, the MIB modules for IEEE 802.1 and IEEE 802.3 were 
developed in the IETF Bridge MIB and Hub MIB Working Groups, 
respectively. With travel budgets under pressure, it has become 
increasingly difficult for companies to fund employees to attend both 
TEEE 802 and IETF meetings. 


As a result, an alternative was found to past arrangements that 
involved chartering MIB work items within an IETF WG. Instead, the 
work was transferred to IEEE 802 with expert support for MIB review 
from the IETF. The process of transfer of the MIB work from the IETF 
Bridge MIB WG to IEEE 802.1 WG is documented in [RFC4663]. 


By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing 
the IETF SNMP quality control process, the IETF and IEEE 802 seek to 
ensure quality while decreasing overhead. In order to encourage 
wider review of MIBs developed by IEEE 802 WGs, it is recommended 
that MIB modules developed in IEEE 802 follow the MIB guidelines 
[BCP111]. An IEEE 802 group may request assignment of a "MIB Doctor" 
to assist in a MIB review by contacting the IETF Operations and 
Management Area Director. 


2. AAA Review 


IEEE 802 WGs requiring new AAA applications should send a liaison 
request to the IETF. Where new attribute definitions are sufficient, 
rather than defining new authentication, authorization, and 
accounting logic and procedures, an Internet-Draft can be submitted 
and review can be requested from AAA-related WGs such as the RADEXT 
or DIME WGs. 


In addition to the RADEXT and DIME WGs, a "AAA doctors" team 
(directorate) is currently active in the OPS Area and can be 
consulted for more general advice on AAA issues that cross the limits 
of one or the other of the RADIUS or Diameter protocols, or are more 
generic in nature. 


For attributes of general utility, particularly those useful in 
multiple potential applications, allocation from the IETF standard 
attribute space is preferred to creation of IEEE 802 Vendor-Specific 
Attributes (VSAs). As noted in [RFC3575]: "RADIUS defines a 
mechanism for Vendor-Specific extensions (Attribute 26) for functions 
specific only to one vendor’s implementation of RADIUS, where no 
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interoperability is deemed useful. For functions specific only to 
one vendor’s implementation of RADIUS, the use of that should be 
encouraged instead of the allocation of global attribute types." 


Where allocation of VSAs are required, it is recommended that IEEE 
802 create a uniform format for all of IEEE 802, rather than having 
each IEEE 802 Working Group create their own VSA format. The VSA 
format defined in [IEEE80211F] is inappropriate for this, since the 
Type field is only a single octet, allowing for only 255 attributes. 
It is recommended that IEEE 802 Working Groups read and follow the 
recommendations in "RADIUS Design Guidelines" [BCP158] and "Protocol 
Extensions" [RFC6929] when designing and reviewing new extensions and 
attributes. 


"Diameter Applications Design Guidelines" [DADG] explains and 
clarifies the rules to extend the Diameter base protocol [RFC6733]. 
Extending Diameter can mean either the definition of a completely new 
Diameter application or the reuse of commands, Attribute-Value Pairs 
(AVPs), and AVP values in any combination for the purpose of 
inheriting the features of an existing Diameter application. The 
recommendation for reusing existing applications as much as possible 
is meaningful as most of the requirements defined for a new 
application are likely already fulfilled by existing applications. 
It is recommended that IEEE 802 Working Groups read and follow the 
recommendations in [DADG] when defining and reviewing new extensions 
and attributes. 


A.3. EAP Review 


The Extensible Authentication Protocol (EAP), defined in [RFC3748], 
provides a framework within which authentication mechanisms, known as 
methods, can be defined. In addition to supporting authentication, 
EAP also provides for key derivation as described in [RFC5247]. 

State machines for EAP are described in [RFC4137]. 


As noted in [BCP132] and [RFC5247], security issues can arise in 
integration of EAP within lower layers. Therefore, it is recommended 
that IEEE 802 WGs looking to incorporate support for EAP send a 
liaison request to the IETF, requesting assistance in carrying out a 
security review. As an example, a security review of IEEE 802.16 was 
carried out by the EAP WG, at the request of IEEE 802.16 
[IEEE-802.16-Liaisonl1l] [IEEE-802.16-Liaison2]. Where development of 
new EAP authentication methods is sufficient, an Internet-Draft can 
be submitted and review can be requested from WGs such as the EAP 
Method Update (EMU) WG. 
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Appendix B. Pointers to Additional Information 


This section provides pointers to additional useful information for 
participants in IEEE 802 and IETF. 


B.1. IEEE 802 Information 
IEEE 802 Home Page: <http://ieee802.org/> 


IEEE 802 policies and procedures: 
<http://ieee802.org/devdocs.shtml> 


The IEEE 802 WG and TAG main page URLs follow this convention: They 
have the one- or two-digit numerical designation for the WG or TAG 
appended after <http://ieee802.org/>. For example the IEEE 802.1 
main web page is at <http://ieee802.org/1>, while the IEEE 802.11 
main web page is at <http://ieee802.org/11>. 


B.2. IETF Information 


Information on IETF procedures may be found in the documents in the 
informative references and at the URLs below. 


Note: RFCs do not change after they are published. Rather, they are 
either obsoleted or updated by other RFCs. Such updates are tracked 
in the rfc-index.txt file. 


Current list and status of all RFCs: 
<http://www.rfc-editor.org/rfc-index.html> 


Current list and description of all IETF Internet-Drafts: 
<ftp://ftp.ietf.org/internet-drafts/lid-abstracts.txt> 


Current list of IETF Working Groups and their Charters: 
<http://datatracker.ietf.org/wg/> (includes Area Directors and chair 
contacts, mailing list information, etc.) 


Current list of requested BOFs: 
<http://trac.tools.ietf.org/bof/trac/> 


RFC Editor pages about publishing RFCs: 
<http://www.rfc-editor.org> (including available tools and guidance) 


<http://www.rfc-editor.org/pubprocess.html> is particularly helpful. 


Current list of liaison statements: 
<https://datatracker.ietf.org/liaison/> 


Dawkins, et al. Informational [Page 34] 


REC 7241 


IEEE 802/IETF Relationship 


July 2014 


IETF Intellectual Property Rights Policy and Notices: 


<http://www.ietf.org/ipr/> 


The Tao of the IETF: <http://www.ietf.org/tao.html> 
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